home *** CD-ROM | disk | FTP | other *** search
/ TOS Silver 2000 / TOS Silver 2000.iso / online / CABDEMO / DOCS / PROGMING / MODUL_D.DOC < prev    next >
Encoding:
Text File  |  1998-08-29  |  20.8 KB  |  495 lines
  1. Kurze Beschreibung der Modulschnittstelle für CAB.APP (bzw. HTML.APP).
  2. ----------------------------------------------------------------------
  3.  
  4. Updates
  5. -------
  6. Ab CAB 2.7 (11/1997):
  7. - set_cookie
  8. - get_url_cookie
  9. - get_url_ifmod_cookie
  10. - post_cookie
  11.  
  12.  
  13. Kontakt
  14. -------
  15. email: aclauss@hrzpub.tu-darmstadt.de
  16.  
  17.  
  18. Hinweise
  19. --------
  20. Das Programm CAB.APP besitzt keine Routinen um online auf das Internet
  21. (bzw. das WWW) zuzugreifen. Der Grund ist: ich habe kein Modem und könnte
  22. diese Routinen deshalb auch nicht testen. Über ein externes Modul
  23. (CAB.OVL) können diese Routinen aber nachgerüstet werden.
  24.  
  25. Die Schnittstelle soll auch unter Single-TOS funktionieren, daher werden
  26. keine speziellen Mint-Features verwendet. Sollte sie für bestimmte Module
  27. unbrauchbar sein, bitte ich um Nachricht.
  28.  
  29. Die Schnittstelle kann an einigen Stellen noch erweitert und verbessert
  30. werden. Sie enthält wahrscheinlich auch ein paar überflüssige Aufrufe, die
  31. zwar in irgendwelchen Alpha-Version eines Moduls benutzt wurden, aber
  32. jetzt höchst wahrscheinlich niemand mehr benutzen wird (z.B. begin_pexec(),
  33. end_pexec() wurden benötigt, weil für die ersten Versuche ein ZMODEM
  34. Programm gestartet wurde, um Daten zu übertragen).
  35.  
  36. Vorschläge zur Verbesserung bzw. Erweiterung der Modul-Schnittstelle werden
  37. gerne entgegengenommen.
  38.  
  39.  
  40. Aufruf des Moduls
  41. -----------------
  42. Es gibt (zur Zeit) zwei Möglichkeiten:
  43.  
  44. 1) CAB.APP läd das Modul CAB.OVL mit pexec(3,...). Das Modul wird dadurch
  45.    in den Speicher geladen und reloziert, aber nicht gestartet. Nun sucht
  46.    CAB.APP nach einer 'magic number' im Speicherbereich des Moduls. Direkt
  47.    hinter dieser Zahl erwartet es die Adresse der Initialisierungs-Routine
  48.    des Moduls. Nun springt es diese Funktion an und übergibt die Adressen
  49.    zweier Strukturen. Eine dieser Strukturen enthält Funktionen, die
  50.    CAB.APP zur Verfügung stellt, und die vom Modul verwendet werden können.
  51.    Die andere Struktur muß von der Initialisierungs-Funktion des Moduls
  52.    ausgefüllt werden, diese muß dort die Adressen der Modul-Funktionen
  53.    eintragen damit sie von CAB.APP aufgerufen werden können.
  54.  
  55.    Die 'magic number' ist:
  56.         0x48744d6c, 0x2f577757, 0x2d42724f, 0x77536552
  57.    CAP.APP gibt dabei nach dem Laden des Moduls mit mshrink() den vom
  58.    Modul nicht benötigten Speicher frei.
  59.  
  60.    Muss das Modul diesen mshrink() Aufruf selbst durchführen, dann muß die
  61.    'magic number' flgendermaßen lauten:
  62.         0x48744d6c, 0x2f577757, 0x2d42724f, 0x77536572
  63.  
  64.    Nachteil dieser Methode: Der Startupcode des Moduls wird nicht
  65.        ausgeführt (und deshalb sind alle Aufrufe von Funktionen die im
  66.        Startupcode initialisiert werden, nicht möglich (betrifft z.B.
  67.        printf()).
  68.  
  69. 2) Als Alternative ist es auch möglich, daß ein Programm, welches die
  70.    Funktionen des Moduls bereitstellt, CAB.APP selbst nachstartet. In
  71.    diesem Fall muß CAB.APP mit dem Parameter -initfunc=<adresse> in der
  72.    Kommandozeile aufgerufen werden. <adresse> steht dabei für die Adresse
  73.    der init-Funktion (in dezimaler Darstellung, also nicht(!) Hexadezimal).
  74.    Die 'Magic Number' wird in diesem Falle nicht benötigt.
  75.  
  76.    Unter Mint mit Memory-Protection muß man dann die Memory-Flags auf
  77.    GLOBAL setzen (bei beiden Programmen), da beide Programme Routinen des
  78.    jeweils anderen aufrufen.
  79.  
  80.  
  81. Aufrufkonventionen
  82. ------------------
  83. Alle Funktionsparameter müssen auf dem Stack übergeben werden. Das
  84. Ergebnis wird im Register D0 übergeben. Variablem vom Typ 'long' sind 32
  85. Bit breit, vom Typ 'int' 16 Bit. Bit 0 bezeichnet das niederwertigste Bit
  86.  
  87. Das bedeutet für Pure C: Alle Funktionen mit 'cdecl' deklarieren
  88. Das bedeutet für den gcc: Die Option '-mshort' verwenden.
  89.  
  90.  
  91. Beschreibung der Funktionen des Moduls
  92. --------------------------------------
  93. In 'modul.h' und 'init.c' (zusammengestellt von Stephane Boisson) befindet
  94. sich schon ein Grundgerüst eines Moduls. Für Aufrufmethode 1) muß man
  95. in main() (welches nie ausgeführt wird) einige Dummy-Aufrufe machen, damit
  96. der Compiler nicht alle Funktionen wegoptimiert.
  97.  
  98. Das Modul CAB.OVL kann folgende Funtionen implementieren:
  99.  
  100.    init_module, get_url_info, get_version, get_url
  101.    post, restore_module, mailto, get_url_if_modified
  102.    
  103. Nur zwei dieser Funktionen (init_module, get_url) müssen implementiert werden, 
  104. alle anderen sind nicht zwingend notwendig, aber für volle online-Funktions-
  105. fähigkeit durchaus wichtig. 
  106.  
  107.  
  108.  
  109. long init_module(url_methods_t *out, browser_info_t *in, char *path);
  110. ---------------------------------------------------------------------
  111. Diese Funktion ruft CAB.APP direkt nach dem Start auf. In dieser Funktion
  112. muß sich das Modul initialisieren.
  113.  
  114.    'path'   enthält den Pfad in dem sich das Modul befindet
  115.             (abgeschlossen durch '\').
  116.    'in'     enthält alle Funktionen, die CAB-APP dem Modul zur
  117.             Verfügung stellt.
  118.    'out'    In diese Struktur müssen die Adressen der Modul-
  119.             Funktionen eingetragen werden. Für Funktionen, die
  120.             nicht implementiert sind, setzt man 0L als Adresse
  121.             ein.
  122.  
  123. Als Ergebnis muß die Funktion einen Bitvektor (long) zurückliefern, indem
  124. die vom Modul unterstützten WWW-Protokolle eingetragen wurden.
  125.  
  126. Konstanten für die Protokolle (mit 'Oder' zu veknüpfen):
  127.    SUPPORT_HTTP, SUPPORT_FTP, SUPPORT_GOPHER, SUPPORT_WAIS,
  128.    SUPPORT_MAILTO, SUPPORT_NNTP, SUPPORT_TELNET
  129.  
  130. Falls das Modul weitere Programme mit pexec(0) startet, muß man zusätzlich
  131. noch folgendes in den Bitvektor eintragen:
  132.    SUPPORT_PEXEC
  133.  
  134. Falls die Initialisierung nicht klappt muß 0L zurück geliefert werden;
  135. weitere Aufrufe von Modul-Funktionen finden dann nicht mehr statt.
  136.  
  137. Wichtig für Aufrufmethode 1 (siehe oben):
  138. Die Adresse dieser Funktion muß direkt hinter der 'Magic number' irgendwo
  139. im Programm- oder Datenbereich untergebracht werden, damit CAB.APP diese
  140. Funktion findet und aufrufen kann (gilt nur wenn das Modul mit pexec(3)
  141. von CAB.APP geladen wurde).
  142.  
  143. Wichtig für Aufrufmethode 2 (siehe oben):
  144. Das Modul wird als Programm gestartet, und startet dann selbst CAB.APP,
  145. wobei es die Adresse dieser Funktion als Parameter übergibt:
  146.  
  147.    Parameter:  -initfunc=<adresse>
  148.  
  149.  
  150. void restore_module(void);
  151. --------------------------
  152. Wird aufgerufen, bevor sich CAB.APP beendet. Die Funktion sollte hier allen
  153. angeforderten Speicher freigeben, geöffnete Datein schliessen, etc.
  154.  
  155. Diese Funktion muß nicht implementiert werden, wenn nichts dauerhaft
  156. reserviert wurde (Dateihandles, Speicher, etc.)
  157.  
  158.  
  159. void get_version(char **authorp, long *versionp, long *datep);
  160. --------------------------------------------------------------
  161. Erfragt Informationen über Autor, Version und Datum des Moduls. Alle
  162. Angaben werden im 'About...' Dialog von CAB.APP angezeigt.
  163.  
  164.    'authorp'   Autor und Kontaktadresse. Maximal 4 Zeilen zu je 30 Zeichen.
  165.                Als Zeilentrenner bitte '|' verwenden.
  166.    'versionp'  Version im BCD-Format. Oberes Wort enthält die Haupt-
  167.                versionsnummer, das untere Wort die Unterversionsnummer.
  168.    'datep'     Datum im BCD-Format: 0xYYYYMMDD (Jahr, Monat, Tag)
  169.  
  170. Diese Funktion muß nicht implementiert werden.
  171.  
  172.  
  173. long get_url_info(char *url, long *timep, long *sizep, char *type);
  174. -------------------------------------------------------------------
  175. Über das Dokument mit der URL-Adresse 'url' sollen einige Informationen
  176. ermittelt werden. Diese Funktion wird aufgerufen um zu entscheiden, ob ein
  177. Dokument überhaupt aus dem Internet angefordert werden muß, oder ob das
  178. Dokument im Cache noch aktuell ist.
  179.  
  180.    'url'    URL-Adresse des Dokuments, über das Informationen gefordert
  181.             werden.
  182.    'timep'  Hier muß das Datum (letzte Modifikation) eingetragen werden.
  183.             Im UNIX-Format: Sekunden seit 1970 (01.01.1970,00:00 => *timep=0)
  184.    'sizep'  Hier soll die Länge (in bytes) des Dokuments eingetragen werden.
  185.             -1L wenn nicht feststellbar.
  186.    'type'   Der Dateityp im MIME-Format. Der String-Puffer bietet Platz für
  187.             250 Zeichen. Oder Leerstring '\0', falls unbekannt.
  188.  
  189. Als Ergebnis leifert die Funktion 0, wenn alles geklappt hat, sonst eine
  190. GEMDOS, XBIOS, BIOS, Mint bzw. MintNet Fehlernummer.
  191.  
  192. Diese Funktion muß nicht implementiert werden. Ist für optimale Cache-
  193. Verwaltung aber sinnvoll.
  194.  
  195.  
  196. long get_url(char *url, char *filename);
  197. ----------------------------------------
  198. Das Modul soll das Dokument mit der URL-Adresse 'url' aus dem Internet
  199. holen und in der Datei 'filename' speichern. 'filename' enthält schon den
  200. kompletten Zugriffspfad; Verzeichnisse müssen nicht mehr angelegt werden.
  201. Das Dateidatum sollte korrekt auf das Datum der letzten Modifikation des
  202. Dokuments gesetzt werden. Nur so funktioniert die Cache-Verwaltung in
  203. Verbindung mit der 'get_url_info(..)' Funktion.
  204.  
  205. Sollte das Ziel der URL-Adresse ein Verzeichnis sein (z.B. beim ftp, gopher
  206. Protokoll) sollte das Ergebnis als HTML-Datei abgelegt werden (falls das
  207. nicht schon automatisch im HTML-Format ankommt???). Wenn man die
  208. Verzeichniseinträge mit Icons versieht, kann man die folgenden eingebauten
  209. Icons benutzen:
  210.  
  211.    #define BULLET_FOLDER "<img src=\"internal-gopher-menu\">"
  212.    #define BULLET_TEXT "<img src=\"internal-gopher-text\">"
  213.    #define BULLET_IMAGE "<img src=\"internal-gopher-image\">"
  214.    #define BULLET_MOVIE "<img src=\"internal-gopher-movie\">"
  215.    #define BULLET_SOUND "<img src=\"internal-gopher-sound\">"
  216.    #define BULLET_INDEX "<img src=\"internal-gopher-index\">"
  217.    #define BULLET_BINARY "<img src=\"internal-gopher-binary\">"
  218.    #define BULLET_UNKNOW "<img src=\"internal-gopher-unknown\">"
  219.  
  220. Als Ergebnis leifert die Funktion 0, wenn alles geklappt hat, sonst eine
  221. GEMDOS, XBIOS, BIOS, Mint bzw. MintNet Fehlernummer.
  222.  
  223. Wird die URL-Adresse umgeleitet (Image-Maps,...) muß man dies CAB.APP
  224. mit der Funktion  'new_url' (siehe unten) mitteilen.
  225.  
  226.  
  227. long get_url_cookie(char *url, char *filename, char *cookie);
  228. ------------------------------------------------------------
  229. Identisch zu get_url, bis auf den zusätzlichen Parameter "cookie".
  230. In "cookie" steht die Cookie-Information für die jeweilige URL (oder 0L, 
  231. falls keine Cookie-Information vorhanden). 
  232.  
  233.  
  234. long post(char *url,char *content, char *enctype, char *filename);
  235. ------------------------------------------------------------------
  236. Die Daten ('content') einer FORM-Umgebung werden mit 'POST' an 'url'
  237. geschickt. Die Daten liegen im 'enctype' (MIME) Format vor. Zur Zeit ist
  238. nur 'application/x-www-form-urlencoded' möglich.
  239. Eventuell zurückgeschickte Daten sollen in 'filename' gespeichert werden.
  240.  
  241. Sollten die zurückgeschickten Datein eine neue URL-Adresse besitzen, dann
  242. unbedingt die Funktion 'new_url' (siehe unten) benutzen.
  243.  
  244.  
  245. long post_cookie(char *url,char *content, char *enctype, char *filename, char *cookie);
  246. --------------------------------------------------------------------------------------
  247. Identisch zu post, bis auf den zusätzlichen Parameter "cookie".
  248. In "cookie" steht die Cookie-Information für die jeweilige URL (oder 0L, falls
  249. keine Cookie-Information vorhanden). Wenn diese Funktion implementiert wird,
  250. so muß auch post implementiert werden.
  251.  
  252.  
  253. long mailto(char *url, char *subject, char *filename);
  254. ------------------------------------------------------
  255. Die Datei 'filename' soll als Mail verschickt werden. 'url' bezeichnet
  256. die Email-Adresse des Empfängers als URL, 'subject' ist der Betreff.
  257. Als Ergebnis liefert die Funktion 0, falls alles geklappt hat, sonst -1.
  258.  
  259.  
  260. long get_url_if_modified(char *url, char *filename, long *timep);
  261. -----------------------------------------------------------------
  262. Kombination aus get_url und get_url_info. CAB versucht zuerst mit
  263. get_url_if_modified auf die Daten zuzugreifen, falls diese Funktion 
  264. implementiert ist. Ist diese Funktion nicht implementiert, werden
  265. get_url und get_url_info verwendet.
  266.  
  267. CAB.OVL muss die url nur dann aus dem WWW holen und unter dem Dateinamen
  268. filename abspeichern, wenn die Daten neuer aus timep (Unix-Format) sind.
  269. Sind die Daten nicht neuer, sollte die Funktion ohne Fehlermeldung (d.h. 
  270. mit 0) zurückkehren. Da hier, im Gegensatz zur Funktion get_url_info(), 
  271. nicht die Länge der Daten zurückgeliefert werden kann (die Funktion kehrt 
  272. ja erst dann zurück, wenn alle Daten komplett geladen wurden), sollte die
  273. Länge über 'msg_status(STATUS_DATALENGTH,len)' an CAB übermittelt werden.
  274.  
  275.  
  276. long get_url_ifmod_cookie(char *url, char *filename, long *timep, char *cookie);
  277. ------------------------------------------------------------------------------
  278. Identisch zu get_url_if_modified, bis auf den zusätzlichen Parameter "cookie".
  279. In "cookie" steht die Cookie-Information für die jeweilige URL (oder 0L, falls
  280. keine Cookie-Information vorhanden). Wenn diese Funktion implementiert wird,
  281. so muß auch get_url_if_modified implementiert werden (beide sind aber optional).
  282.  
  283.  
  284.  
  285.  
  286. Funktionen, die CAB.APP anbietet (browser_info_t Struktur)
  287. ----------------------------------------------------------
  288. Das Modul kann direkt AES-Aufrufe machen, im Allgemeinen ist das aber nicht
  289. nötig.
  290.  
  291. void (*aes_crystal)(void)
  292. -------------------------
  293. Für AES-Aufrufe bitte die folgenden Arrays ausfüllen und dann 'aes_crystal'
  294. aufrufen.
  295.  
  296.   int *aes_control;
  297.   int *aes_global;
  298.   int *aes_intin;
  299.   int *aes_intout;
  300.   long *aes_addrin;
  301.   long *aes_addrout;
  302.  
  303. void (*aes_messages)(int *msg)
  304. ------------------------------
  305. Besitzt das Modul eine eigene AES-Event-Behandlung, sollte bei jedem
  306. MU_MESAG-Event (bzw. jedem Event, welches nicht das Modul betrifft) der
  307. Ereignis-Puffer mit dieser Funktion an CAB.APP weitergereicht werden, damit
  308. dieses z.B. Redraws ausführen kann.
  309.  
  310.  
  311.  
  312. void (*msg_error)(long errno)
  313. -----------------------------
  314. Gibt eine Fehlermeldung aus (im Statusfenster von CAB.APP). Erlaubt sind alle
  315. GEMDOS, BIOS und MintNet Fehlernummern.
  316.  
  317.  
  318. void (*msg_status)(long no,long val)
  319. ------------------------------------
  320. Gibt eine der folgenden Statusmeldngen aus:
  321.  
  322.    no=1: 'connecting host',                val unbenutzt
  323.    no=2: 'receive data',                   val=Anzahl der empfangenen Bytes
  324.    no=3: 'waiting for response',           val unbenutzt
  325.    no=4: 'resolving host',                 val unbenutzt
  326.    no=5: 'sending request',                val unbenutzt
  327.    no=6: 'Text formatieren...',            val unbenutzt
  328.    no=7: 'Bild laden...',                  val unbenutzt
  329.    no=8: 'Starte Programm...',             val unbenutzt
  330.    no=9: 'Formatiere Tabelle...',          val unbenutzt
  331.    no=10: 'Warte auf Daten (Timeout: #)',  val=Timeout
  332.    no=11: 'Konvertiere Bild...',           val unbenutzt
  333.  
  334.    no=12345  val=Länge der Daten
  335.           Hiermit kann das OVL jederzeit die Länge der zu übertragenden 
  336.           Daten an CAB übermitteln. Dies ist insbesondere dann wichtig,
  337.           wenn get_url_if_modified aufgerufen wurde, da CAB hier nicht
  338.           die Länge der Daten zurückgeliefert bekommt.
  339.              
  340.  
  341. Weitere Meldungen können bei Bedarf aufgenommen werden. Nummern bitte mit
  342. mir absprechen.
  343.  
  344.  
  345. long (*aes_events)(long msec)
  346. -----------------------------
  347. Mit dieser Funktion gibt man CAB.APP die Gelegenheit auf AES-Ereignisse zu
  348. reagieren. CAB.APP ruft evnt_multi(MU_MESAG|MU_TIMER|MU_KEYBD,..) auf,
  349. wobei 'msec' als Zeit für das Timer-Event benutzt wird. Mit einem kleinen
  350. Wert für 'msec' kehrt die Funktion also schnell wieder zurück. CAB.APP ver-
  351. arbeitet zunächst alle eigenen Events (z.B. Redraw, Fenster verschieben,..)
  352. und prüft, ob der Benutzer die Aktion abbrechen will. Als Ergebnis liefert
  353. die Funktion:
  354.  
  355.           0     -> kein MU_MESAG-Event. Weitermachen.
  356.          -1     -> Aktion abbrechen (Benutzer hat ESC gedrückt).
  357.    alles andere -> Pointer auf ein GEM-Message-Array (int msg[8]) mit den
  358.                    Daten des aktuellen MU_MESAG-Ereignises.
  359.  
  360.  
  361. long (*alert_box)(long button,long msg)
  362. ---------------------------------------
  363. Eine Alertbox wird dargestellt. 'button' ist der Default-Button und 'msg'
  364. die Nummer eines Textes. Die Funktion liefert 0, wenn ein Fehler auftrat
  365. (falsche msg Nummer), sonst den ausgewählten Button.
  366. Mögliche Texte (msg):
  367.  
  368.    msg=0 : "[2][Aktion abbrechen?][Ja|Nein]"
  369.    msg=1 : "[1][Transaktion war erfolgreich][Abbruch]"
  370.    msg=2 : "[1][Transaktion war nicht|erfolgreich][Abbruch]"
  371.  
  372. Weitere Texte können bei Bedarf aufgenommen werden. Nummer bitte mit mir
  373. absprechen.
  374.  
  375.  
  376. void (*begin_pexec)(void)    void (*end_pexec)(void)
  377. ----------------------------------------------------
  378. Mit diesen beiden Funktionen muß das Starten eines Programmes durch pexec(0)
  379. geklammert werden. CAB.APP wird sich unter Single-TOS beim AES korrekt ab-
  380. und danach wieder anmelden.
  381.  
  382.  
  383. int (*clear_cache)(long size)
  384. -----------------------------
  385. Sorgt dafür, daß mindestens 'size' Bytes im Cache frei sind. Gegebenenfalls
  386. werden einige Dateien (auf die am längsten nicht mehr zugegriffen wurde)
  387. aus dem Cache entfernt. Konnte soviel Platz geschaffen werden, liefert die
  388. Funktion 0 sonst -1.
  389. size=0 bedeutet, daß der komplette Cache gelöscht wird.
  390.  
  391.  
  392. int (*new_url)(char *url,char **file)
  393. -------------------------------------
  394. Wenn eine Dokument-Anfrage auf eine neue URL-Adresse umgeleitet wird (z.B.
  395. Imagemaps, cgi-Scripts), muß man dies dem Hautprogramm mit dieser Funktion
  396. mitteilen. Es ermittelt dann einen neuen Dateinamen 'file', unter dem die
  397. Daten dann abgespeichert werden müssen. Liefert die Funktion als Ergebnis 0
  398. soll das Dokument jetzt endgültig geholt werden, liefert sie als Ergebnis
  399. -1, dann muß das Dokument nicht mehr geholt werden, da es sich schon im
  400. Cache befindet.
  401.  
  402.  
  403. int (*ask_user)(long msg,char **answer)
  404. ---------------------------------------
  405. Wenn der Benutzter bestimmte Angaben machen muß, bevor fortgefahren werden
  406. kann (z.B. bei geschützten Dokumenten mit Passwortabfrage), kann man diese
  407. Angaben hiermit anfordern.
  408. 'msg' ist die Nummer des Textes, der angezeigt wird, 'answer' ist der
  409. String, der vom Benutzer eingegeben wurde. Das Resultat ist 1 wenn der
  410. Benutzter OK gedrückt hat, 0 für Abbruch und -1 bei einem Fehler (falsche
  411. 'msg'-Nummer). Der String 'answer' wird beim nächsten Aufruf dieser Funktion
  412. wieder überschrieben daher, wenn nötig, umkopieren.
  413. Möglicher Werte für 'msg':
  414.  
  415.    msg=0 : Dokument geschützt, Name (bzw. Kennung) eingeben
  416.    msg=1 : Dokument geschützt, Passwort eingeben
  417.  
  418. Weitere Texte können bei Bedarf definiert werden. Bitte mit mir absprechen.
  419.  
  420.  
  421. long basepage
  422. -------------
  423. Adresse der Modul-Basepage. Nur gültig, wenn Modul mit pexec(3) gestartet
  424. wurde.
  425.  
  426. int *reloadflag
  427. ---------------
  428. Zeiger auf ein integer. Der Integerwert ist 1, wenn der Benutzer 'Neu laden'
  429. (Reload) ausgewählt hat, sonst 0. Kann dazu verwendet werden, eventuell gecachete
  430. Informationen/Daten zu benutzen oder nicht.
  431.  
  432.  
  433. long version
  434. ------------
  435. Versionsnummer von CAB im ASCII format. Beispiel: V1.30 wäre 0x30313330.
  436.  
  437.  
  438. proxy_url *proxy
  439. ----------------
  440. Zeiger auf die folgende Struktur:
  441.  
  442. struct {
  443.    char *ftp_proxy;
  444.    char *http_proxy;
  445.    char *wais_proxy;
  446.    char *gopher_proxy;
  447.    char *news_proxy;
  448.    char *no_proxy;
  449.    char *smtp_server;
  450.    char *nntp_server;
  451. } proxy_url
  452.  
  453. Das OVL sollte diese Struktur innerhalb der init-Funktion mit
  454. Default-Werten ausfuellen. CAB hat fuer jeden String schon Speicher
  455. (126 Bytes) reserviert. CAB wird diese Einträge ändern, falls der
  456. Benutzter neue Einträge in CAB bestimmt. Das OVL sollte deshalb
  457. vor dem Download der Daten diese Einträge erneut inspizieren.
  458.  
  459.  
  460. void online(int state)
  461. ----------------------
  462. Sollte vom OVL immer dann aufgerufen werden, wenn die Internet-
  463. verbindung aufgebaut bzw. abgebrochen wird. Besteht die Verbindung
  464. muß state=1 sonst state=0 übergeben werden. Diese Funktion darf
  465. ab CAB-Version 1.41 aufgerufen werden (d.h.: version>=0x30313431).
  466. Wird diese Funktion vom OVL nicht aufgerufen, geht CAB davon aus,
  467. daß die Internetverbindung besteht. Sinnvoll einsetzbar ist die
  468. Funktion allerdings erst, wenn das CAB.OVL in einem eigenen Thread
  469. Änderungen des Online-Statuses überprüft, da das OVL von CAB nur
  470. bei Bedarf aufgerufen wird.
  471.  
  472.  
  473. void set_cookie(char *url, char *name, char *value, char *expires,
  474.                 char *path, char *domain, int secure)
  475. -----------------------------------------------------------------
  476. Hiermit kann das OVL einen "Cookie", der aus der HTTP-Antwort
  477. extrahiert wurde, setzen. Je nach getätigten Einstellungen wird CAB
  478. den Cookie in die Cookie-Datenbank einfügen, den Benutzer fragen,
  479. oder den Cookie ignorieren.
  480.  
  481. url     - ist die URL des Dokuments, für das der Cookie geliefert wurde.
  482. name    - Name des Cookies
  483. value   - Wert des Cookies (oder 0, falls kein Wert gesetzt)
  484. expires - Verfallsdatum (oder 0, falls nicht gesetzt) als String im
  485.           Format "Wdy, DD-Mon-YYYY HH:MM:SS GMT"
  486. path    - Zugriffspfad, für den der Cookie gültig ist.
  487. domain  - Domain, für den der Cookie gültig ist
  488. secure  - 0 für die normale (unsichere) Übertragung, 1 für sicheres HTTPS.
  489.  
  490. Diese Funktion ist verfügbar seit CAB 2.7 (d.h. Version>=0x30323730)
  491. und(!) wenn derentsprechende Eintrag in der Struktur nicht 0L ist.
  492.  
  493.  
  494.  
  495.